Skip to content

Conversation

@andrewdnolan
Copy link
Collaborator

@andrewdnolan andrewdnolan commented Jul 23, 2025

⚠️ Work in Progress: This release is not planned until November 2025. Some preliminary work was done in order to familiarize @andrewdnolan with the e3sm-unified configuration and deployment process. Release candidates have been tested on chrysalis, but have not been uploaded to conda-forge.

In this version

  • Many packages have been updated, including:

    • chemdyg 1.1.1
    • e3sm_diags 3.1.0
    • e3sm_to_cmip 1.13.0
    • livvkit 3.2.0
    • mache 2.0.0
    • esmf 8.9.0
    • esmfpy 8.9.0
    • hdf5 1.14.6
    • mache 1.31.0
    • mpas_analysis 1.14.0
    • mpas_tools 1.4.0
    • nco 5.3.6
    • pcmdi_metrics 4.0.0
    • tempest-extremes 2.4
    • xcdat 0.10.1
    • zppy 3.1.0
    • zppy-interfaces 0.2.0
    • zstash 1.5.0
    • dask 2025.9.1
    • matplotlib 3.10.6
    • proj 9.6.2
    • pyproj 3.7.2
    • xarray 2025.9.0
  • python versions 3.11, 3.12, and 3.13 will be supported

New and improved

TBD

Deployment

Deployed on:

  • Andes
  • Anvil
  • Aurora
  • Chrysalis
  • Compy
  • Dane
  • Frontier
  • Perlmutter-CPU
  • ALCF Polaris

Sync Diagnostics

Synced on:

  • Andes
  • Anvil
  • Aurora
  • Chrysalis
  • Compy
  • Dane
  • Frontier
  • Perlmutter-CPU
  • ALCF Polaris

Delete old test envs

  • Anvil
  • Chrysalis
  • Compy
  • Dane
  • Frontier
  • Perlmutter-CPU

@xylar
Copy link
Contributor

xylar commented Jul 24, 2025

@andrewdnolan, one thing we need to figure out is how to set permissions on the base conda environment and its contents such that multiple maintainers can create environments but users can't install packages into the environment by mistake.

My thought here is that it might be safer to introduce a conda directory similar to the spack directory and to have fresh conda installations under e3sm_unified_1_12_0, etc. So what was base now becomes conda/e3sm_unified_1_12_0 or whatever. This way, we could set permissions such that conda is group writable but e3sm_unified_1_12_0, etc. and their contents are only writable by one maintainer.

Could you look into this? The relevant code to fix would be:
https://github.com/E3SM-Project/e3sm-unified/blob/main/e3sm_supported_machines/shared.py#L132-L133
The function would need to take the version number and convert it to the desired syntax with underscores, similar to what is done for spack path names here:
https://github.com/E3SM-Project/e3sm-unified/blob/main/e3sm_supported_machines/bootstrap.py#L112-L117
But we don't need the machine, compiler or MPI variant because the conda base environment doesn't care about those things.

Changes default version of python to 3.13 and release versions to
be 3.11, 3.12, and 3.13. To support the new python versions all
CDAT related packages have been removed from the `meta.yaml`
and the associated testing of `cdms2` in the `bootstrap.py` file.
The `pcmdi_metrics` package is currently commented out of the
`meta.yaml` because it has `genutils`, `cdutils`, `cdms2`, and `cdp`
as dependencies. When a new version of `pcmdi_metrics`, without CDAT
dependencies, is released it will be uncommented out of the `meta.yaml`.

With the update to python 3.13 the build string for the python version
has changed and is now dealt with accordingly.
A cmake based build system was introduce in version 2.3.0.
The spack package recipe for TempestExtremes uses a cmake build
system, so a version >=2.3.0 is now neeed
Also simplified the spack environment name given that the spack
installation lives within a versioned e3sm-unified direcotry.
base_path = config.get('e3sm_unified', 'base_path')
spack_base = f'{base_path}/{env_name}/{machine}/'
spack_base_path = (
f'{base_path}/{env_name}/{machine}/spack/spack_for_{compiler}_{mpi}'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this addition the directory layout(on chrysalis) would look like:

$ tree -L 4 /lcrc/soft/climate/e3sm-unified/
/lcrc/soft/climate/e3sm-unified/
├── e3sm_unified_x_x_x
│   └── chrysalis
│       ├── base
│       ├── spack
│       │   └── spack_for_gnu_openmpi

for e3sm-unified where there's only ever on compiler and mpi combination, maybe the intermidate spack folder is unneeded. Happy to defer to you about that @xylar.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the spack folder is redundant for now but consistent with future plans, right? Let's keep it for consistency.

- jupyter
- livvkit 3.1.0
- mache 1.28.0
- mache 1.31.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During deployment, please use the branch:
https://github.com/E3SM-Project/mache/tree/update-to-2.0.0
with the --mache_fork and --mache_branch flags.

Feel free to update that branch (which includes E3SM-Project/mache#303) as needed to get things working.

We can make a release candidate when we know that things are working but right now it feels premature.

# the version of mache to use during deployment (should match the version used
# in the package itself)
mache = 1.28.0
mache = 1.31.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can leave this for now but will eventually need to be 2.0.0rcX once we have a release candidate.

andrewdnolan and others added 6 commits October 6, 2025 10:34
Update package version to be in sync with confluence page

Co-authored-by: Xylar Asay-Davis <[email protected]>
Remove constraint on notebook which was for compatability
with nb_conda, which has been removed. notebook has been
left in, without constraint, so that jupyter notebooks are
still avaialable
@xylar
Copy link
Contributor

xylar commented Oct 15, 2025

Group write permission

I enabled group write permission on the E3SM-Unified base directories on:

  • Andes
  • Anvil
  • Aurora
  • Chrysalis
  • Compy
  • Dane
  • Frontier
  • Perlmutter-CPU
  • ALCF Polaris
  • Ruby

I don't have access to Ruby or Dane. I am renewing my Compy access.

xylar and others added 4 commits October 23, 2025 11:09
This is necessary to avoid a SbangPathError in spack on Frontier.

This merge also drops the requirement that the machine be specified.
There is no longer an attempt to use a shared conda base environment
as the conda environment for bootstrapping.  Instead, the person
deploying Unified must supply the `--conda` flag or have a base
environment loaded before deploying.
The deploy and bootstrap scripts are now getting totally different
conda bases in totally different ways so a shared function doesn't
make sense anymore.  This merge splits the functionality back into
these 2 scripts for better clarity and simplicity.
Now consitent with the new layout for e3sm-unified
This is needed to unload a problem module on ALCF Polaris and
may be useful on other machines in the future.

This requires a new capability in mache.
@andrewdnolan
Copy link
Collaborator Author

@xylar would mind looking over the most recent commit?

Assuming you're OK with the approach/layout here, I'll get cranking on the NCO PR.

@xylar
Copy link
Contributor

xylar commented Oct 27, 2025

@andrewdnolan, as discussed on slack, looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants